The growing importance of the Internet and of mobile communication creates the demand to attach mobile computing devices adapted for wireless communication with mobile nodes to the Internet. The original Internet Protocol (IP) does not support mobile communication, therefore the Internet protocols must be augmented with mobility support.
The BRAIN Candidate Mobility Protocol (BCMP) is an example of a communication protocol that allows a network to provide wireless Internet access for mobile computers. BCMP is further described in IST-1999-10050 BRAIN, “BRAIN Architecture specifications and models, BRAIN functionality and protocol specification,” published on Mar. 30, 2001. Mobile computers adapted for BCMP is allowed to connect to a BCMP network and can send and receive data packets to and from other computers connected to the Internet.
FIG. 1 illustrates a BCMP network 100. The BCMP network 100 comprises gateways 108, routers 106, Access Routers (AR) 104 and Mobile Nodes (MN) 102. At least one of the routers 106, is an Anchor Point (ANP) that owns and allocates IP addresses, authenticates users, maintains user records, and tunnels packets towards the Mobile Nodes (MN) 102, e.g. laptops, which are connected to the IP network via the ARs 104. The ARs 104 is connected to a wireless interface towards the MNs 102 and route information received from the MNs 102 further into the IP network. The ARs 104 are called BRAIN Access Routers (BAR) within the BCMP network 100. Each AR is adapted to terminate tunnels from the ANPs and forwards packets to/from mobile hosts, e.g. terminals such as mobile phones, laptops or palmtop computers. The gateways 108 (i.e. border routers towards e.g. Internet) are called BRAIN Mobility Gateways (BMG) in BCMP. The gateways 108 are not required to have BCMP specific functionality. The role of the gateways 108 is to shield the rest of the BCMP network from the exterior routing protocols and to distribute traffic to the appropriate ANPs 106. Besides these entities, the BCMP network 100 can also incorporate other network entities, such as AAA servers that store and manage user related information, Network Management functions, Quality of Service functions, Resource Management function, etc.
Each ANP 106 has globally routable address space and it allocates an IP address to the MN 102 when the MN 102 attach to the BCMP network 100. This address is kept constant, despite handovers. The handover procedure is described further below. The pool of IP addresses owned by the ANP 106 is advertised using legacy IP routing inside the BCMP network 100 and toward external IP networks. This ensures that packets addressed to the address of the MN 102 obtained locally are routed, by means of standard IP routing, to the ANP 106 that allocated the address. The Anchor Points 106, in turn, use IP-in-IP encapsulation to forward packets to the AR 104 where the MN 102 that is the destination is located at the moment.
When the MN 102 first contacts the AR 104 it must execute a login procedure. First it sends a login request message to the AR 104 at which it has appeared. In this request the MN 102 provides login and security information (e.g., mobile user identifier). The AR 104 selects the ANP 106 for the MN 102 according to a policy specified by an operator and forwards the login request to it. The MN 102 is not required to be aware of the policy and of the internal structure of the AR 104. The selected ANP 106 identifies and authenticates the MN 102 and allocates a globally routable IP address and a new session identifier for the MN 102. The session identifier is a temporary identifier used to index control messages in the BCMP network 100. The session identifier, a security key and the IP address are sent back to the MN 102 in a login response message.
As the MN 102 move, it can connect to a new AR 104 when necessary. This is called a handover. The ANPs 106 must maintain up-to-date location information of MNs 102 they have allocated an address for and must update this information when ‘their’ MNs 102 move to another AR 104. For this purpose, the ARs 104 notify ANPs 106 when the handover occurs. In addition, the BCMP can incorporate various local handover mechanisms that improve the performance of handover by, for example, building a temporary path from the old AR 104 to the new AR 104 in order to avoid loss of data packets sent to the MN 102.
If the MN 102 moves far away from its ANP 106 then the tunnel between the ANP 106 and AR 104 may become very long. In order to avoid long tunnels, the BCMP allows (but does not mandate) the network operator to request that the MN 102 changes the ANP 106. This improves routing efficiency in the network, in exchange for exposing mobility toward the Internet: the change of the ANP 106 requires a change of the MN's 102 IP address, which is a global mobility event. Alternatively, the operators may choose to accept long tunnels between the ANPs and the ARs in order to completely hide mobility from external networks.
The BCMP protocol provides a paging support that allows the MNs to enter idle mode and to reduce location update signalling load inside the AR.
FIG. 2, illustrates a paging scenario in a BCMP network. The BCMP network 200 comprises the following nodes: a gateway 212 connected to the Internet 214, routers 210,214, wherein some of the routers are ANPs 208,216, ARs 204,206 and a MN 202. The nodes within the BCMP network exemplified by FIG. 2 comprise the same functionality as the network depicted in FIG. 1. The MN 202 is in idle mode when it is turned on but is not involved in transmission of voice, data or certain time sensitive control information in contrast to active mode that occurs when the MN 202 is involved in such transmission. When the MN changes its state to then it informs its AR 204 about the mode change and performs handover in active mode when it moves 226 to the new AR 206 (as long as it stays within the same group of ARs 204,206 called a Paging Area (PA) PA1). The ARs are not notified about the handover, which results in that the ARs will not know in which AR:s proximity the MN 202 is found. When data packets 218 are sent to the MN 202, these 218 will still be routed to MN's 202 old AR 204. This AR 204 knows that the MN 202 is idle and hence instead of transmitting its packets through the radio interface, it multicasts a paging request message 220 to all ARs 204,206 within the paging area PA1. Each AR 204,206 forwards the paging request 220 through its radio interface on a common control channel directed to the correct MN 202. When the MN receives the paging request 220, it performs a BCMP handover 222 and returns to normal mode of operation. This allows its packets to be routed to the MN 202.
If, while in idle mode, the MN 202 moves 228 to an AR 224 that belongs to a different paging area PA2 than its old AR 204, then it performs a handover and returns to idle state immediately. The rest of the operation is the same as the steps described above.
The drawback of the paging mechanism specified by BCMP is that paging request messages 220 must be sent out by the ARs 204,206,224 and hence the ARs 204,206,224 must know which ARs 204,206,224 belong to the same paging area. This means that the configuration and possible reconfiguration of paging areas involves communication with ARs. If, for example, a new AR is added to the network than in addition to configuring this AR, all the other ARs in the same paging area must be notified so they can update their paging areas.
There are additional drawbacks of the BCMP paging mechanism if the operator employs advanced paging schemes. A paging scheme defines the list and order of ARs where the MN is paged when it has incoming data packets. An advanced paging scheme may require, for example, that a particular user is always paged first through one particular AR and next through the ARs of its paging area. In this case, the BCMP paging scheme requires that this scheme is known by each AR, which causes significant configuration and processing load on the ARs.
As another insufficiency, the BCMP protocol as described above contains no functions that would enable operators to determine which mobile nodes are located in certain parts of the network (e.g., for location aware services). Therefore, it is not possible to trigger external entities when certain users/nodes move into or outside pre-defined areas if their movement matches a certain pattern e.g. speed and direction. For example, an owner of a coffee shop would like to send an ad to each user that enters the district containing the coffee shop. This could be a service provided by the BCMP network, but it needs location management function. A pre-defined area is specified as a set of cells. A cell is the coverage area of a wireless access point within an access router. In this example, an area could be the cell that contains the coffee shop, plus all neighbouring cells. As another service, the ad would be sent to each user that is moving toward the coffee shop. This service requires a location management infrastructure.
HMIPv6 is another protocol for mobile IP that has a similar network architecture to BCMP. The drawback of HMIPv6 regarding the location management is identical to BCMP. One difference between BCMP and HMIPv6 is that HMIPv6 uses IETF (Internet Engineering Task Force) Mobile IPv6 message formats.